Method and system for logic verification using mirror interface

ABSTRACT

Verification of external interfaces of cores on system-on-chip (SOC) designs frequently entails the purchase of costly standardized software models to test the external interfaces. Typically, the standardized models provide more functionality than is needed. Instead of standardized models, test models may be developed and utilized, but this also incurs cost and delay. The present invention provides an efficient and economical alternative. A mirror interface, or copy of the external interface undergoing verification, is used with a standardized control mechanism to verify the external interface. Because all interface I/O connections can thereby be utilized, a cost-effective and highly reusable way of verifying such interfaces is provided.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/986,773, filed on Nov. 15, 2004. Application Ser. No. 10/986,773 is acontinuation of U.S. application Ser. No. 09/826,035, filed Apr. 4,2001, now issued as U.S. Pat. No. 6,865,502. The listed applications areassigned to International Business Machines Corporation and the entirecontents of each of these applications are incorporated herein byreference.

BACKGROUND

The present invention relates generally to the verification ofintegrated circuit (IC) logic, and more particularly to a method andsystem for increasing the efficiency and re-usability of verificationsoftware.

Before ICs are released to market, the logic designs incorporatedtherein are typically subject to a testing and de-bugging process knownas “verification.” Verification of logic designs using simulationsoftware allows a significant number of design flaws to be detected andcorrected before incurring the time and expense needed to physicallyfabricate designs.

Software verification typically entails the use of software “models” ofdesign logic. Such models may be implemented as a set of instructions ina hardware description language (HDL) such as Verilog®. or VHDL®. Themodels execute in a simulation environment and can be programmed tosimulate a corresponding hardware implementation. The simulationenvironment comprises specialized software for interpreting model codeand simulating the corresponding hardware device or devices. By applyingtest stimuli (typically in batches known as “test cases”) to a model insimulation, observing the responses of the model and comparing them toexpected results, design flaws can be detected and corrected.

Advances in technology have permitted logic designs to be packed withincreased density into smaller areas of silicon as compared with past ICdevices. This has led to “system-on-a-chip” (SOC) designs. The term“SOC” as used herein refers to combinations of discrete logic blocks,often referred to as “cores,” each performing a different function orgroup of functions. A SOC integrates a plurality of cores into a singlesilicon device, thereby providing a wide range of functions in a highlycompact form. Typically, a SOC comprises its own processor core (oftenreferred to as an “embedded” processor), and will further comprise oneor more cores for performing a range of functions often analogous tothose of devices in larger-scale systems.

In its developmental stages a core is typically embodied as asimulatable HDL model written at some level of abstraction, or in amixture of abstraction levels. Levels of abstraction that are generallyrecognized include a behavioral level, a structural level, and a logicgate level. A core may be in the form of a netlist including behavioral,structural and logic gate elements.

Verification of a SOC presents challenges because of the number of coresand the complexity of interactions involved, both between the coresinternally to the SOC, and between the SOC and external logic. Anacceptable level of verification demands that a great number of testcases be applied, both to individual components of the SOC, and to thecores interconnected as a system and interfacing with logic external tothe SOC. There is a commensurate demand on computer resources and time.Accordingly, techniques which increase the efficiency of verificationare at a premium.

According to one standard technique, already-verified models are used totest other models. The electronic design automation (EDA) industry hasreached a level of sophistication wherein vendors offer standardizedmodels for use in verification of other models still in development. Inparticular, such models are typically used for testing cores in a SOCthat have external interfaces (i.e., communicate with logic external tothe SOC). Such standardized models save the purchaser developmentresources, are typically well-tested and reliable, and are designed tohave a wide range of applicability.

However, there are disadvantages associated with using standardizedmodels. For instance, they can be very costly. Moreover, they can bevery complex and provide much more functionality than is needed by thepurchaser if only a subset of functions are required. Further, thestandardized models must be integrated into existing verificationsystems, incurring more cost in terms of time and effort.

Alternatively to purchasing and using standardized models, designersmay, of course, develop their own testing models. However, this iscostly in terms of development time, with the typical result that suchmodels are designed for limited application. Accordingly, they typicallyhave limited functionality and re-usability.

An approach is needed to address the concerns noted in the foregoing.

SUMMARY

The present invention overcomes shortcomings of existing art byproviding an efficient and economical method and system for testingexternal interfaces of cores in an SOC. According to the invention, amirror interface is attached to an external interface of a coreundergoing verification. The mirror interface is a copy or duplicate ofthe interface undergoing verification.

In a preferred embodiment, a standardized, programmable controlmechanism is utilized to enable a test case executing in the SOC, forpurposes of verifying the external interface, to configure the mirrorinterface as needed for data transfers to and from the externalinterface. The control mechanism controls data flow, transfer direction,and data checking.

In the foregoing embodiment, the mirror interface is attached to a busfunctional model containing a memory model for storing data receivedfrom the external SOC interface during testing, and a processor modelfor emitting CPU bus cycles. A bi-directional communication mechanism isprovided to enable communication between the SOC and the controlmechanism.

Because the mirror interface is an exact copy of the external interfaceundergoing verification, all the I/O connections of the interfaces canbe used. Moreover, because the control mechanism is standardized, theinvention is highly re-usable. Further, the control mechanism isprogrammable to be readily adaptable to different interfaces.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows a verification test bench according to the presentinvention;

FIG. 1B shows execution domains of a test case and the control mechanismaccording to the invention;

FIG. 2 shows connections and signals exchanged between a SOC and a busfunctional model and mirror interface via a bidirectional generalpurpose I/O device;

FIG. 3 shows a process flow of control code for handling data flow,transfer direction, and data checking; and

FIG. 4 shows a general purpose computer system for implementing theinvention.

DETAILED DESCRIPTION

FIG. 1A shows an embodiment of the present invention in the form of averification test bench 1. The term “test bench” is well known in thesimulation/verification field, and refers to a compiled andsimulation-ready computer program including a model or models to besimulated. A verification test bench provides all of the externalstimulus needed to test a SOC or part of an SOC, and receives stimulusfrom the SOC. The test bench is provided with the stimulus for aparticular test case, and then compiled by a simulator. The simulatorloads the compiled test bench into the simulator to conduct the testcase.

Thus, FIG. 1A (and FIGS. 1B and 2, discussed in greater detail below)are to be understood, in general terms, as representing a softwaresimulation of a physical system. Accordingly, when terms such as“connected,” “attached” or “coupled,” as represented by lines connectingblock elements in the Figures, are used in the following, reference isbeing made to a software counterpart of physical means for propagatingsignals between block elements.

As shown in FIG. 1A, a SOC 100 includes a core 101 having an externalSOC interface. An example of core having an external interface is theperipheral component interconnect (PCI) interface core used in manysystems throughout the electronics industry, which interfaces with anexternal PCI bus. For example, if the SOC is part of a circuit card, andthe circuit card has a PCI bus attached to another device, the PCI corewould interface with the device via the bus.

The core 101 is connected via a processor bus 106 to an embeddedprocessor (central processing unit or CPU) core 102. Also connected tothe processor bus 106 is a memory controller core 103 having aninterface to a memory 104 external to the SOC.

In the example of FIG. 1A, the core 101 is undergoing verification ofits external SOC interface. According to the invention, a mirrorinterface 101M is connected to the core 101 undergoing verification ofits external interface. The mirror interface 101M is a copy of theinterface undergoing verification. (It is noted that, as used herein,the term “interface” refers to the set of input and output signals bymeans of which a core or model communicates with other logic. It isfurther noted that the terms “core” and “core interface” or “interface”are interchangeable in the respect that, regardless of its internalstructure, any core may be defined in terms its interface wherecommunication with other logic is concerned.)

Because the mirror interface is simply a copy of an already existinginterface, there is no need to develop a new test model or purchase acostly standardized model. Moreover, the interface-to-interface couplingis, in effect, “ready-made,” since the mirror interface has exactly thesame inputs and outputs as the interface undergoing verification.

A bus functional model (BFM) 105 is attached to the external mirrorinterface 101M. BFMs are well known in the simulation/verificationfield. The BFM essentially models an internal SOC bus 109 and aprocessor model 110 for emitting CPU bus cycles to emulate the behaviorof a processor, but without requiring the computer resources needed tofully simulate an actual processor. A memory model 107 is also attachedto the BFM, so that if any data is sent through the interface 101, offthe SOC to the external mirror interface 101M, the data can be stored inthe memory model 107 and retrieved and checked if needed.

The invention further comprises a consistent, standardized controlmechanism which is easily adaptable to different interfaces. Thestandardized control mechanism comprises a standardized “handshake,” orcommunication protocol, between the SOC and the external mirrorinterface. The control mechanism further comprises programmable controlcode executing in the BFM which controls data flow, transfer direction,and data checking. Because the code is programmable, it is easilyadaptable to different interfaces. The control code may be implementedin a bus functional language (BFL).

An external bidirectional general purpose I/O (GPIO) 108 may be providedto allow communication between the SOC and external logic. The externalbidirectional GPIO comprises a plurality of bidirectional buses whichcan be connected between the SOC and external models/cores. Internallogic in the GPIO provides for control and status monitoring of coresconnected to the bidirectional buses by enabling functions includingdriving data on the buses, reading the current state of data on thebuses, and capturing positive and negative edge transitions on thebuses.

In conducting a given verification procedure on an external SOCinterface, the particular set of verification stimuli that are appliedto the SOC interface depends on a test case. The test case is typicallydesigned to conduct a range of exercises for an interface, to determinewhether it performs as expected. The test case generates specifiedstimuli, for example, directives to read or write data. The test casereceives results corresponding to the stimuli, and compares them againstexpected results to verify correct performance.

The test case utilizes the standardized control mechanism of theinvention to direct the application of test stimuli to an external SOCinterface as desired. The test case executes in the SOC and issuesdirectives in the standardized handshake protocol for initiating andcontrolling operations by the mirror interface.

A typical test case comprises exchanging data between the SOC interface101 and its external mirror counterpart 101M. To prepare for theexchange of data, a given interface must typically be appropriatelyconfigured, i.e., programmed to receive and/or send data, store data andthe like. The test case utilizes the GPIO 108 to configure and controlthe external mirror interface 101M via the BFM 105. Using thestandardized handshake, the test case generates control directives inthe form of signals which are transmitted via the GPIO to the controlcode executing in the BFM. The code continuously waits for the GPIOinput to the BFM to determine whether some action is being required ofthe mirror interface by a test case.

FIG. 1B illustrates execution domains of the test case and control codeaccording to the invention. A test case 120 executes in the SOC 100 andissues control directives 122 to the control code 121 executing in theBFM 105. The GPIO 108 transfers the control directives from the SOC tothe BFM.

FIG. 2 illustrates connections between the SOC 100 and GPIO 108, andGPIO 108 and BFM 105, in greater detail. An application by a test caseof a data transfer process for verifying an SOC interface according tothe invention is discussed in the following with reference to FIG. 2.

To transfer data from the SOC interface 101 to the mirror interface101M, a test case executing in the SOC utilizes control directivesincluding, for example, RUN 200, DESCRIPTOR 201, DONE 202 and STATUS 203signals of the standardized handshake protocol. First, the test casesends a RUN signal 200 and a DESCRIPTOR signal 201 to the bidirectionalGPIO 108. The RUN signal tells the code executing in the BFM toconfigure the mirror interface for a data transfer. The DESCRIPTORsignal includes such information as data transfer direction (in thiscase, from the SOC interface 101 to the mirror interface 101M), thenumber of pieces of data to transfer, the size of the data pieces, thetransfer mode, and the like.

The GPIO 108 transfers the RUN and DESCRIPTOR signals to the BFM 105,and the test case waits to receive a DONE signal 202 from the BFMindicating that the configuration of the mirror interface is complete.

The GPIO transfers the DONE signal from the BFM to the test caseexecuting in the SOC. When the test case detects the DONE signal, itbegins the data transfer. The control code replies with a STATUS signaland the DONE signal after the data has been received, and the test caseevaluates the STATUS signal (good/bad) and reports the results.

To transfer data from the mirror interface 101M to the SOC interface101, a test case executing in the SOC sends the RUN and DESCRIPTORsignals via the GPIO to the BFM. In this case, the direction parameterof the DESCRIPTOR signal specifies that the data transfer is from themirror interface to the SOC interface.

The test case waits to receive a DONE signal 202 from the BFM indicatingthat the configuration of the mirror interface is complete. When thetest case detects the DONE signal, it sends a RUN signal 200 back to theBFM, and expects the data transfer from the mirror interface to the SOCinterface to begin.

The mirror interface 101M transfers data to the SOC interface 101, andsends STATUS and DONE signals after it has finished transferring thedata. The SOC test case detects the DONE signal and evaluates thereceived data to determine success or failure. The STATUS signal reportswhether any transfer errors were detected by the BFM.

As noted above, the control code executes in the BFM attached to themirror interface. The control code functions, in part, as the externalsurrogate of the test case executing in the SOC, performing operationsanalogous to test case operations, based on the handshake signalsgenerated by the test case.

A process flow for the control code, according to one possibleformulation, is shown in FIG. 3. As shown in blocks 300 and 301, thecontrol code waits continuously for a RUN signal from the test caseexecuting in the SOC.

Depending on the direction information of the DESCRIPTOR signal, thecode configures the mirror interface to either send or receive data, asshown in blocks 302, 303 and 308. The configuration is the only portionof the control code which is interface-dependent, and it can be readilyaltered to adjust to whatever interface is being verified.

If the mirror interface is to receive data, the control code sends theDONE signal to the SOC once the mirror interface is configured, as shownin block 304. Then, the test case sends the data through the SOCinterface 101 to the mirror interface 101M, as shown in block 305. Thecontrol code includes logic for verifying whether the correct data wasreceived, as shown in block 306. The code sends STATUS and DONE signalsback to the SOC, reporting that the data transfer is finished andwhether it was successful, as shown in block 307.

If the mirror interface is to send data, the control code sends the DONEsignal to the SOC once the mirror interface is configured, as shown inblocks 308-309. Then, as shown in block 310, the control code waits fora RUN signal from the test case.

When the RUN signal is received, the control code sends the data throughthe mirror interface 101M to the SOC interface 101, and thereby to thetest case executing in the SOC, as shown in block 311. When it isfinished sending data, the control code sends STATUS and DONE signals tothe SOC, reporting that the data transfer is finished, as shown in block312. The test case can then evaluate to data to determine whether thetransfer was successful.

It may be appreciated that the invention as disclosed hereinaboveprovides considerable advantages. The invention is highly reusable withdifferent interfaces because of the programmable nature of the controlcode executing in the mirror interface. Moreover, the invention providesprecisely the amount of functionality needed because the test interfaceis a mirror copy of the interface undergoing verification, andaccordingly all or a subset of all interface I/O connections can beused. Additionally, the use of costly standardized test models isavoided.

FIG. 4 shows a computer system which can used to implement the presentinvention. The system includes a computer 400 comprising a memory 401and processor 402 which may be embodied, for example, in a workstation.The system may include a user interface 403 comprising a display device404 and user input devices such as a keyboard 405 and mouse 406.

The verification test bench 1, as noted above, may be implemented ascomputer-executable instructions which may be stored on computer-usablemedia such as disk storage 407, CD-ROM 408, magnetic tape 409 ordiskette 410. The instructions may be read from a computer-usable mediumas noted into the memory 401 and executed by the processor 402 to effectthe advantageous features of the invention.

A simulator 411 loaded into computer memory 401 and executed byprocessor 402 interprets a compiled verification test bench 1 tosimulate hardware devices corresponding thereto. The simulator 411 maybe any of a variety of commercially available simulators, includingevent simulators, cycle simulators and instruction set simulators.

Programming structures and functionality implemented incomputer-executable instructions as disclosed hereinabove for performingsteps of the method may find specific implementations in a variety offorms, which are considered to be within the abilities of a programmerof ordinary skill in the art after having reviewed the specification.

The foregoing description of the invention illustrates and describes thepresent invention. Additionally, the disclosure shows and describes onlythe preferred embodiments of the invention, but it is to be understoodthat the invention is capable of use in various other combinations,modifications, and environments and is capable of changes ormodifications within the scope of the inventive concept as expressedherein, commensurate with the above teachings, and/or the skill orknowledge of the relevant art. The embodiments described hereinabove arefurther intended to explain best modes known of practicing the inventionand to enable others skilled in the art to utilize the invention insuch, or other, embodiments and with the various modifications requiredby the particular applications or uses of the invention. Accordingly,the description is not intended to limit the invention to the formdisclosed herein. Also, it is intended that the appended claims beconstrued to include alternative embodiments.

1. A verification test bench system used in testing in a core which isused in a design, the system comprising: a processor configured toimplement a bus functional model coupled, through a mirror interface, toan external interface of a core undergoing verification and memory,wherein the mirror interface is an exact copy of the external interface;a bi-directional general purpose I/O device; and a control mechanismcomprising: means for implementing a standardized handshake protocolbetween the design and the mirror interface; and a source for controlcode which, when loaded into the bus functional model, controls dataflow, transfer direction, and data checking when a test case is runningin the design.
 2. The verification test bench system of claim 1, whereinsaid core is coupled to said external interface, and said controlmechanism issues directives in said handshake protocol to initiate andcontrol an exchange of data between said mirror interface and theexternal interface.
 3. A verification method comprising: attaching amirror interface to an external interface of a core in a system-on-chip(SOC) undergoing verification, wherein the mirror interface is an exactcopy of the external interface; and executing a test case in said SOCwhich applies test stimuli to said external interface using said mirrorinterface.
 4. The method of claim 3, further comprising providing acontrol mechanism for enabling said test case to configure and controlsaid mirror interface.
 5. The method of claim 4, wherein said providinga control mechanism comprises: implementing a standardized handshakeprotocol for communicating with said SOC; and providing control code forconfiguring said mirror interface and transferring data to said externalinterface via said mirror interface.
 6. The method of claim 5, furthercomprising: issuing directives in said handshake protocol using saidcontrol code to configure said mirror interface; and initiating datatransfer between said mirror interface and said external interface.
 7. Acomputer program product tangibly embodied on a computer-usable medium,said program product comprising computer-executable instructions whichwhen executed implement a process comprising the steps of: connecting anexternal interface of a core on to a mirror interface of said externalinterface, wherein the mirror interface is an exact copy of the externalinterface; and executing a test case in a system-on-chip (SOC) design toapply test stimuli for verification of said external interface via saidmirror interface.
 8. The computer program product of claim 7, saidprocess further comprising executing a control mechanism for enablingsaid test case to control said mirror interface.
 9. The program productof claim 7, said process further comprising implementing communicationmeans for enabling said test case to communicate with said mirrorinterface.